If you use Sidekick and the XML parser, then when a large XML file is edited, jEdit
becomes very slow, even freezing, unless you turn off parsing in Sidekick first. For
example, download and open the XML file at http://www.tellurianring.com/images/movies_list_data_1m.xml
and hit Ctrl+End. On my system, jEdit will peg out at 50% CPU and remain frozen for
a couple of minutes.
The problem goes away if in the Plugins options dlg, SideKick sxn, I turn off all
three "Auto parsing Settings": "Parse on buffer switch", "Parse on buffer save", and
"Parse on keystroke."
Be sure your folding mode set to "Sidekick" to reproduce this error.
| Submitted | adblockfreak - 2010-06-15 - 21:54:02z | Assigned | kerik-sf |
|---|---|---|---|
| Priority | 5 | Category | None |
| Status | Open | Group | None |
| Resolution | None | Visibility | No |
| 2010-06-15 - 21:55:23z adblockfreak |
System info: OS: Windows XP Pro, Service Pack 2 Java: 1.6.0_18 according to the first test at http://www.javatester.org/version.html jEdit: 4.3.1 Sidekick 0.9 XML 2.6.1 XSLT 0.6.0 |
|---|---|
| 2010-12-08 - 23:44:06z ezust |
Moving to plugin bugs tracker. |
| 2011-06-19 - 12:47:35z kerik-sf |
progress has been made in r19545 and r19597. Now, SidekickTagHighlight is active by default : it uses Sidekick to locate the matching tag for matching tag highlight. Doing so reduces parsing a lot and loading movies_list_data_1m.xml and hitting Ctrl+End won't block for so long. It still takes a long time to parse these big files into a Sidekick tree and to create the corresponding UI (thousands of tree nodes). Another thing that speeds things up is to use the buffer's content directly (buffer.getSegment()) instead of making a copy (buffer.getText()). This is visible when moving the caret around near the end of movies_list_data_1m.xml to trigger matching tag highlight. |